SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Serviceability (computer)</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Serviceability (computer)</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">For other uses, see <a href="Serviceability_(disambiguation)" class="mw-redirect mw-disambig" title="Serviceability (disambiguation)">Serviceability (disambiguation)</a>.</div>

<p>In <a href="Software_engineering" title="Software engineering">software engineering</a> and <a href="Hardware_engineering" class="mw-redirect" title="Hardware engineering">hardware engineering</a>, <b>serviceability</b> (also known as <b>supportability</b>) is one of the -<a href="Ilities" class="mw-redirect" title="Ilities">ilities</a> or aspects (from IBM's <a href="Reliability%2C_availability_and_serviceability_(computer_hardware)" class="mw-redirect" title="Reliability, availability and serviceability (computer hardware)">RAS(U)</a> (Reliability, Availability, Serviceability, and Usability)). It refers to the ability of <a href="Technical_support" title="Technical support">technical support</a> personnel to install, configure, and monitor computer products, identify exceptions or faults, <a href="Debugging" title="Debugging">debug</a> or isolate faults to <a href="Root_cause_analysis" title="Root cause analysis">root cause analysis</a>, and provide hardware or <a href="Software_maintenance" title="Software maintenance">software maintenance</a> in pursuit of solving a problem and restoring the product into service. Incorporating serviceability facilitating features typically results in more efficient product maintenance and reduces operational costs and maintains business continuity.

</p><p>Examples of features that facilitate serviceability include:

</p>

<ul><li><a href="Help_desk" title="Help desk">Help desk</a> notification of exceptional events (e.g., by <a href="Electronic_mail" class="mw-redirect" title="Electronic mail">electronic mail</a> or by sending <a href="Plain_text" title="Plain text">text</a> to a <a href="Pager" title="Pager">pager</a>)</li>

<li><a href="Network_monitoring" title="Network monitoring">Network monitoring</a></li>

<li><a href="Documentation" title="Documentation">Documentation</a></li>

<li><a href="Event_logging" class="mw-redirect" title="Event logging">Event logging</a> / <a href="Tracing_(software)" title="Tracing (software)">Tracing (software)</a></li>

<li>Logging of <a href="Program_state" class="mw-redirect" title="Program state">program state</a>, such as

<ul><li>Execution path and/or local and <a href="Global_variables" class="mw-redirect" title="Global variables">global variables</a></li>

<li>Procedure entry and exit, optionally with incoming and return variable values (see: <a href="Subroutine" class="mw-redirect" title="Subroutine">subroutine</a>)</li>

<li>Exception block entry, optionally with local state (see: <a href="Exception_handling" title="Exception handling">exception handling</a>)</li></ul></li>

<li><a href="Software" title="Software">Software</a> <a href="Upgrade" title="Upgrade">upgrade</a></li>

<li><a href="Graceful_degradation" class="mw-redirect" title="Graceful degradation">Graceful degradation</a>, where the product is designed to allow recovery from exceptional events without intervention by <a href="Technical_support" title="Technical support">technical support</a> staff</li>

<li><a href="Computer_hardware" title="Computer hardware">Hardware</a> replacement or upgrade planning, where the product is designed to allow efficient hardware upgrades with minimal <a href="Computer_system" class="mw-redirect" title="Computer system">computer system</a> <a href="Downtime" title="Downtime">downtime</a> (e.g., <a href="Hotswap" class="mw-redirect" title="Hotswap">hotswap</a> components.)</li></ul>

<p>Serviceability engineering may also incorporate some routine system maintenance related features (see: Operations, Administration and Maintenance (<a href="OA%26M" class="mw-redirect" title="OA&M">OA&M</a>.))

</p><p>A <b>service tool</b> is defined as a facility or feature, closely tied to a product, that provides capabilities and data so as to service (analyze, monitor, debug, repair, etc.) that product. <b>Service tools</b> can provide broad ranges of capabilities. Regarding diagnosis, a proposed taxonomy of service tools is as follows:

</p>

<ul><li>Level 1: Service tool that indicates if a product is functional or not functional. Describing computer servers, the states are often referred to as ‘up’ or ‘down’. This is a binary value.</li>

<li>Level 2: Service tool that provides some detailed diagnostic data. Often the diagnostic data is referred to as a problem ‘signature’, a representation of key values such as system environment, running program name, etc. This level of data is used to compare one problem’s signature to another problem’s signature: the ability to match the new problem to an old one allows one to use the solution already created for the prior problem. The ability to screen problems is valuable when a problem does match a pre-existing problem, but it is not sufficient to debug a new problem.</li>

<li>Level 3: Provides detailed diagnostic data sufficient to debug a new and unique problem.</li></ul>

<p>As a rough rule of thumb for these taxonomies, there are multiple ‘orders of magnitude’ of diagnostic data in level 1 vs. level 2 vs. level 3 service tools.

</p><p>Additional characteristics and capabilities that have been observed in service tools:

</p>

<ul><li>Time of data collection: some tools can collect data immediately, as soon as problem occurs, others are delayed in collecting data.</li>

<li>Pre-analyzed, or not-yet-analyzed data: some tools collect ‘external’ data, while others collect ‘internal’ data. This is seen when comparing system messages (natural language-like statements in the user’s native language) vs. ‘binary’ storage dumps.</li>

<li>Partial or full set of system state data: some tools collect a complete system state vs. a partial system state (user or partial ‘binary’ storage dump vs. complete system dump).</li>

<li>Raw or analyzed data: some tools display raw data, while others analyze it (examples storage dump formatters that format data, vs. ‘intelligent’ data formatters (“ANALYZE” is a common verb) that combine product knowledge with analysis of state variables to indicate the ‘meaning’ of the data.</li>

<li>Programmable tools vs. ‘fixed function’ tools. Some tools can be altered to get varying amounts of data, at varying times. Some tools have only a fixed function.</li>

<li>Automatic or manual? Some tools are built into a product, to automatically collect data when a fault or failure occurs. Other tools have to be specifically invoked to start the data collection process.</li>

<li>Repair or non-repair? Some tools collect data as a fore-runner to an automatic repair process (self-healing/fault tolerant). These tools have the challenge of quickly obtaining unaltered data before the desired repair process starts.</li></ul>

<ul><li><a href="FURPS" title="FURPS">FURPS</a></li>

<li><a href="Maintainability" title="Maintainability">Maintainability</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<p>Excellent example of Serviceability Feature Requirements:

</p>

<ul><li><a rel="nofollow" class="external text" href="http://www.sun.com/service/gdd/index.xml">Sun Gathering Debug Data (Sun GDD)</a>. This is a set of tools developed by the Sun's support guys aimed to provide the right approach to problem resolution by leveraging proactive actions and best practices to gather the debug data needed for further analysis.</li>

<li>"Carrier Grade Linux Serviceability Requirements Definition Version 4," Copyright (c) 2005-2007 by Open Source Development Labs, Inc. Beaverton, OR 97005 USA <a rel="nofollow" class="external autonumber" href="http://devresources.linux-foundation.org/dev/cgl/cgl40/cgl40-serviceability.pdf">[1]</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2023-01-15" href="https://en.wikipedia.org/wiki/?title=Serviceability_(computer)&oldid=1133819421">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>